Telegram Group & Telegram Channel
AppSec != DevSecOps

Нашу команду часто подключают к процессам выстраивания безопасной разработки в компаниях. В свете продолжающихся изменений регуляторики будут ещё чаще. Помимо вопросов относящихся к специфике HR, существует пул hard skills задач, которые начинаются с четкого определения зоны ответственности человека и требуемых компетенций. Сегодняшний пост посвящен рефлексии и размышлениям о разнице между AppSec, DevSecOps и ProdSec на фоне неоднозначного видения этих ролей в компаниях, что часто приводит к недопониманию на интервью и затрудняет подбор подходящего сотрудника.

Все, что вы прочитаете далее, является субъективным рассуждением на основе эмпирики.

AppSec

Цель: Обеспечение безопасности приложения. Это отражено в KPI, включая количество найденных уязвимостей, охват тестируемых приложений и глубину анализа. В задачи входят анализ архитектуры, моделирование угроз, ревью кода и тестирование безопасности. Роль AppSec существует достаточно давно, с начала 2000-х годов, когда появилась организация OWASP. Хотя о результативности этой роли можно порассуждать, подробнее писали в относительно старом посте.

DevSecOps

Цель: Автоматизация процессов безопасности и интеграция безопасности в DevOps. В KPI входит адаптация инструментов безопасности в SDLC и автоматизация проверок безопасности на уровне CI/CD. Сюда часто включается безопасность платформ Kubernetes и облачных сервисов. Концепция DevSecOps начала формироваться в 2012-2014 годах.

Несмотря на явные различия в целях и задачах, часто можно встретить распределение ролей в командах, где AppSec-инженер в крупной компании, способной разделить ответственность, занимается встраиванием инструментов в CI/CD. При этом у инженера явный уклон именно в безопасность веба и мобильных приложений. В итоге мы видим, что внедрение произошло, но нередко оно выполнено неэффективно, не учитывая многие аспекты, к которым приходят опытные DevOps-инженеры. На рынке AppSec также существует множество кандидатов, приходящих на интервью с единственным опытом встраивания сканеров, многие из которых никогда не работали с инструментами вроде Burp Suite.

Product Security

Кто такие Product Security, о которых мы слышим все чаще последние 2-3 года, особенно на интернациональной рынке? Это команды, занимающиеся безопасностью продукта в целом, включая управление уязвимостями продукта и его инфраструктуры, а также облачную безопасность. Некоторые компании даже имеют команды Product Security как единственных специалистов по безопасности. ProdSec также тесно взаимодействует с Product Management, что нечасто встречается в AppSec. ProdSec интегрирует безопасность в жизненный цикл пользователя, внедряя MFA, историю входов, CAPTCHA и другие механизмы, тесно сотрудничая не только с dev и product, но и с маркетингом и другими бизнес-направлениями. Команде ProdSec, как и AppSec, не обязательно иметь в составе DevSecOps-инженера, который может существовать отдельно в команде DevOps.

Это зарождающееся разделение, где ProdSec получает больше доменов ИБ под управление, обусловлено, на мой взгляд, как и тесным переплетением слоев абстракций (cloud-native инфраструктура) так и непониманием старой школы инфраструктурных безопасников особенностей разработки и того, что нужно делать, чтобы быть гармоничным участником процесса. Любое изменение конфигурации в облаке, применение патча или правила на WAF может сильно повлиять на работу пользователя. Поэтому любое изменение для продуктов, независимо от инфраструктурного или прикладного слоя, может проходить аналогичный цикл SDLC, как и любое изменение кода.

P.S. И в этом процессе возникновения новых ролей можно разглядеть интересный элемент, дополняющий наш любимый shift left. Этакий shift right: когда приложения и процессы становятся все более сложными и запутанными, а мы чтобы приоритезировать необъятное фокусируемся прежде всего на опыте клиента, на том, что находится максимально справа. А затем "раскручиваем" то необходимое, что нужно для того чтобы его опыт состоялся (включая требования к ИБ и соответствие регуляторике).

#имхо



tg-me.com/sec_devops/614
Create:
Last Update:

AppSec != DevSecOps

Нашу команду часто подключают к процессам выстраивания безопасной разработки в компаниях. В свете продолжающихся изменений регуляторики будут ещё чаще. Помимо вопросов относящихся к специфике HR, существует пул hard skills задач, которые начинаются с четкого определения зоны ответственности человека и требуемых компетенций. Сегодняшний пост посвящен рефлексии и размышлениям о разнице между AppSec, DevSecOps и ProdSec на фоне неоднозначного видения этих ролей в компаниях, что часто приводит к недопониманию на интервью и затрудняет подбор подходящего сотрудника.

Все, что вы прочитаете далее, является субъективным рассуждением на основе эмпирики.

AppSec

Цель: Обеспечение безопасности приложения. Это отражено в KPI, включая количество найденных уязвимостей, охват тестируемых приложений и глубину анализа. В задачи входят анализ архитектуры, моделирование угроз, ревью кода и тестирование безопасности. Роль AppSec существует достаточно давно, с начала 2000-х годов, когда появилась организация OWASP. Хотя о результативности этой роли можно порассуждать, подробнее писали в относительно старом посте.

DevSecOps

Цель: Автоматизация процессов безопасности и интеграция безопасности в DevOps. В KPI входит адаптация инструментов безопасности в SDLC и автоматизация проверок безопасности на уровне CI/CD. Сюда часто включается безопасность платформ Kubernetes и облачных сервисов. Концепция DevSecOps начала формироваться в 2012-2014 годах.

Несмотря на явные различия в целях и задачах, часто можно встретить распределение ролей в командах, где AppSec-инженер в крупной компании, способной разделить ответственность, занимается встраиванием инструментов в CI/CD. При этом у инженера явный уклон именно в безопасность веба и мобильных приложений. В итоге мы видим, что внедрение произошло, но нередко оно выполнено неэффективно, не учитывая многие аспекты, к которым приходят опытные DevOps-инженеры. На рынке AppSec также существует множество кандидатов, приходящих на интервью с единственным опытом встраивания сканеров, многие из которых никогда не работали с инструментами вроде Burp Suite.

Product Security

Кто такие Product Security, о которых мы слышим все чаще последние 2-3 года, особенно на интернациональной рынке? Это команды, занимающиеся безопасностью продукта в целом, включая управление уязвимостями продукта и его инфраструктуры, а также облачную безопасность. Некоторые компании даже имеют команды Product Security как единственных специалистов по безопасности. ProdSec также тесно взаимодействует с Product Management, что нечасто встречается в AppSec. ProdSec интегрирует безопасность в жизненный цикл пользователя, внедряя MFA, историю входов, CAPTCHA и другие механизмы, тесно сотрудничая не только с dev и product, но и с маркетингом и другими бизнес-направлениями. Команде ProdSec, как и AppSec, не обязательно иметь в составе DevSecOps-инженера, который может существовать отдельно в команде DevOps.

Это зарождающееся разделение, где ProdSec получает больше доменов ИБ под управление, обусловлено, на мой взгляд, как и тесным переплетением слоев абстракций (cloud-native инфраструктура) так и непониманием старой школы инфраструктурных безопасников особенностей разработки и того, что нужно делать, чтобы быть гармоничным участником процесса. Любое изменение конфигурации в облаке, применение патча или правила на WAF может сильно повлиять на работу пользователя. Поэтому любое изменение для продуктов, независимо от инфраструктурного или прикладного слоя, может проходить аналогичный цикл SDLC, как и любое изменение кода.

P.S. И в этом процессе возникновения новых ролей можно разглядеть интересный элемент, дополняющий наш любимый shift left. Этакий shift right: когда приложения и процессы становятся все более сложными и запутанными, а мы чтобы приоритезировать необъятное фокусируемся прежде всего на опыте клиента, на том, что находится максимально справа. А затем "раскручиваем" то необходимое, что нужно для того чтобы его опыт состоялся (включая требования к ИБ и соответствие регуляторике).

#имхо

BY Security Wine (бывший - DevSecOps Wine)




Share with your friend now:
tg-me.com/sec_devops/614

View MORE
Open in Telegram


DevSecOps Wine Telegram | DID YOU KNOW?

Date: |

What is Telegram Possible Future Strategies?

Cryptoassets enthusiasts use this application for their trade activities, and they may make donations for this cause.If somehow Telegram do run out of money to sustain themselves they will probably introduce some features that will not hinder the rudimentary principle of Telegram but provide users with enhanced and enriched experience. This could be similar to features where characters can be customized in a game which directly do not affect the in-game strategies but add to the experience.

The SSE was the first modern stock exchange to open in China, with trading commencing in 1990. It has now grown to become the largest stock exchange in Asia and the third-largest in the world by market capitalization, which stood at RMB 50.6 trillion (US$7.8 trillion) as of September 2021. Stocks (both A-shares and B-shares), bonds, funds, and derivatives are traded on the exchange. The SEE has two trading boards, the Main Board and the Science and Technology Innovation Board, the latter more commonly known as the STAR Market. The Main Board mainly hosts large, well-established Chinese companies and lists both A-shares and B-shares.

DevSecOps Wine from it


Telegram Security Wine (бывший - DevSecOps Wine)
FROM USA